Conventionally, the recording apparatus are dependent on the processing unit i.e., the recording apparatus are configured to be a part of the processing unit and configured for capturing the screen output of only a monitor attached to the processing unit. These recording apparatus capture the screen output with the help of a software. The software receives specific user instructions for capturing screen output on a particular time or date. Further, the software instructs the recording apparatus to capture and store the screen output on the specified time or date. Hence, these recording apparatus captures and stores the screen output on the specified instructions of the user.
Further, these recording apparatus have no provision for defining or co-relating with an event for automatically capturing screen output when a fault in processing unit or transmission of display signals, etc. is detected. For instance, in critical applications, rebuilding the scenario after a critical failure event is of utmost importance. Normally, conventional recording apparatus make use of video tapes, transaction logs and audit databases to rebuild the scenario to find the actual cause. This rebuilding process may take several days to several weeks to exactly pin point the cause particularly when one or more computer operators are involved to make a key decision. These recording apparatus have no provisions for defining a critical failure event for automatically capturing the scenario.
For example, aircrafts involve a “Black Box” recorder that records every event within the aircraft. In case of a critical failure or a catastrophic event, investigation teams rebuild the scenario based on “black box” readings. Correctly decoding the readings may take a few days and re-constructing the event may require experienced manpower that increases costs and expenses.
Similar critical failures or disaster situations may happen within manufacturing plants (e.g. Oil Gas Platform, pharmaceutical plant, etc). Normally, databases are designed to store key variables and transaction data such as audit logs, input/output signals, digital and analog values, quality readings, security accesses, personnel logs, alarm database, etc with real-time history. Reading and analyzing the large amount of data and re-constructing the event become a cumbersome task and experienced manpower may be required to decode the readings.
Further, capturing screen outputs from multiple screens is not possible using the conventional recording apparatus as one recording apparatus is fixed within one processing unit. For capturing screen output of multiple screens, many recording apparatus will be used thereby increasing the cost and configuration time. In addition, screen capture programs may interfere with existing running applications and memory within primary processing units.
Conventional recording apparatus depend upon the primary memory of the processing unit to store the captured screen outputs. These recording apparatus do not have any internal memory for storage of captured screen outputs thereby occupying the primary memory of the processing unit.
Retrieving and playing the stored screen output on a separate screen or on a separate platform such as web portal or a mobile device is also cumbersome as the conventional recording apparatus uses the capabilities of the processing unit for playing the screen output on the separate platform. The processing unit may or may not have these capabilities of playing the recorded screen outputs on the separate platform.
In order to obviate at least one or more of the aforementioned problems, there is a well-felt need to provide an improved method, a recording apparatus and a system for capturing and storing a screen output of at least one display device.